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(57) Abstract: A system for conducting a commercial 
transaction between a buyer and a seller is disclosed. 
The system includes a transaction processing system for 
facilitating payment for a transaction between the buyer 
and the seller. In addition to the buyer and the seller, 
the transaction processing system also interacts with an 
issuer and an acquirer. The issuer issues and manages 
an account for the buyer. The acquirer manages an ac- 
count for the seller. The transaction processing system 
operates as follows. An electronic invoice relating to 
the transaction is first posted to the system by the seller 
or another system. Upon accepting the electronic in- 
voice, the system creates a payment instruction. Each 
time a payment instruction is created, the system applies 
certain pre-negotiated payment terms and conditions be- 
tween the buyer and the seller to the payment instruc- 
tion. After the payment instruction is created, the sys- 
tem seeks approval from the buyer. Upon approval of 
the payment instruction by the buyer, the system sched- 
ules the payment for the specified date in the payment 
instruction. On die scheduled day of payment, the sys- 
tem calculates one or more fees, such as a transaction 
fee, for the transaction according to a pre-defined variable pricing matrix, which is determined based on a set of pre-negotiated con- 
ditions agreed to by the issuer, the acquirer, the seller and the buyer. For example, the transaction fee is an amount used by the issuer 
and the acquirer to compensate each other for processing the payment on behalf of the buyer and the seller. After the transaction fee 
is calculated, information relating to the transaction fee and the payment instruction is formatted into a proper message format(s) 
and submitted for authorization, clearing and settlement The issuer and the acquirer then communicate with one another directly 
or indirecdy to settle the funds. Additionally, the system provides transaction and activity reports to all relevant parties as well as 
access to status information for invoices and payments. 
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METHOD AND SYSTEM FOR CONDUCTING A COMMERCIAL 
TRANSACTION BETWEEN A BUYER AND A SELLER 

5 BACKGROUND OF THE INVENTION 

[01] The present invention generally relates to commercial transactions, and more 
specifically, to a method and system for conducting a commercial transaction between a 
buyer and a seller. 

[02] In business-to-business transactions, buyers and sellers can establish 
1 0 relationships with one another in a number of different ways. For example, when die 
transactional volume and/or amount reaches a certain level, a buyer and a sella: typically 
enter into a sales agreement to minimize the risks of exposure and breach by either party. In 
addition, when a buyer and a seller wish to establish a long-term relationship with one 
another, they also typically enter into a sales agreement which includes the terms and 
1 5 conditions which govern the rights and obligations of the parties whenever they deal with 
each other, thereby avoiding the need to negotiate terms and conditions for each transaction 
on an ad hoc basis. 

[03] While sales agreements are routinely used by buyers and sellers to establish 
contractual relationships with one another, the terms and conditions of a sales agreement 

20 typically still need to be reviewed and applied to each transaction manually. In other words, 
even, when a buyer and a seller have established a long-term contractual relationship via 
execution of a sales agreement, whenever a transaction is to be completed between the 
parties, both parties still need to manually ensure that the transaction is compliant with the 
terms and conditions of the sales agreement The examination of the terms and conditions of 

25 the sales agreement is usually done by a human being on an individual basis for each 

transsection. This manual examination process is often tedious, time-consuming and prone to 
mors. Therefore, it would be desirable to have a system whicL is capable of storing and 
applying in an automated manner the terms and conditions of a sales agreement between a 
buyer and a seller for transactions conducted between die parties. 

30 [04] Furthermore, a buyer and a seller may have more than one sales agreement 

between the parties. In feet, as between a buyer and a sella: who have a long-term 
relationship, various types of sales agreements often exist and apply to different types of 
transactions between the parties. Manually reviewing these various types of sales agreements 
to determine which specific sale agreement applies to a particular transaction is obviously 
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inefficient Therefore, it would also be desirable to have a system which is capable of 
collectively storing and m aintaining terms and conditions of sales agreements between a 
buyer and a seller. 

[05] A transaction between a buyer and a seller is typically completed in the 
5 following manner. A buyer usually issues a purchase order to a seller for goods and/or 
services which the buyer wishes to purchase. Upon receipt of the purchase order, the seller 
ships the goods to the buyer. The seller generally simultaneously forwards an invoice for the 
amount due when the goods are shipped It is up to the buyer to honor that invoice and pay 
within an agreed upon period of time. Payment by the buyer is typically made via check or 
10 money transfer. Alternatively, payment can also be made via credit cards or similar credit 
arrangements. 

[06] A normal credit card transaction involves a number of parties, including a 
buyer who possesses a credit card, a seller, an acquirer, an issuer and a credit card association 
such as Visa or Mastercard. The acquirer is a business entity, e.g., a commercial bank, that 

15 has a business relationship with the seller and receives all the credit card transactions from 
that seller. The issuer is a business entity which issues the credit card to the buyer. The 
credit card association such as Visa maintains a network of processing applications, e.g., 
VisaNet, which facilitates issuance of credit cards and processing of credit card transactions. 
[07] Atypical credit card transaction involves the folio wing steps. First, the seller 

20 calculates the amount of the transaction or purchase and seeks payment from the buyer. The 
buyer then presents the seller with his/her credit card Hie seller then runs the credit card 
through a point of sale terminal. The point of sale terminal captures credit card and sales 
information and sends such information together with an authorization request to the 
acquirer. The acquirer, in turn, processes the information received from the point of sale 

25 terminal and forwards any relevant information and the authorization request to the issuer. 
The issuer processes the relevant information and the authorization request to determine 
whether the transaction should be authorized. The issuer then sends an approval or denial 
code bade to the acquirer. The acquirer relays the approval or denial code to the point of sale 
terminal for use by the seller. Ifthe transaction is authorized, the buyer is allowed to 

30 consummate the transaction with the seller. Typically, at a later time, the accounts 

maintained by the issuer and the acquirer are settled and reconciled The issuer transfers the 
transaction amount minus a fee to the acquirer. The acquirer then deducts a fee from the 
amount received from the issuer. The remaining amount is then transferred by the acquirer to 
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the seller's account A separate fee is charged by the crectitcaidassodation for use of its 
network to fecilitate the transaction. 

[08] Credit card transactions are generally well accepted. Computer systems have 
been developed to process these transactions in a reliable and secure manner. One such 
5 computer system known as VisaNet is developed by Visa to process credit card transactions. 
Therefore, it would be desirable to have a system which is capable of taking advantage of 
currently available computing resources thereby forther expediting and facilitating 
transactions between buyers and sellers. 

10 SUMMARY OF THE INVENTION 

[09] A system for conducting a commercial transaction between a buyer and a 
sella: is disclosed- The system includes a transaction processing system for facilitating 
payment for a transaction between the buyer and the seller. In addition to the buyer and the 
sella:, the transaction processing system also interacts with an issuer, an acquirer and a credit 
15 card association, such as Visa (via VisaNet). The issuer issues and manages an account for 
the buyer. The acquirer manages an account for the seller. 

[10] Before the transaction processing system is used to process transactions 
between the buyer and the seller, certain information is obtained from the buyer, foe seller, 
the issuer and the acquirer and stored on the system Each buyer and seller are registered in 
20 the system. Upon registration, the pre-negotiated terms and conditions which are to be used 
to govern the transactions between the buyer and the seller are collected and stored on the 
system. Such terms and conditions are obtained, for example, from a sales agreement 
between the buyer and the sella:. In addition, the system also stores pre-negotiated terms and 
conditions agreed to amongst the buyer, the seller, the issuer and foe acquirer. 
25 [111 Hie transaction processing system handles a transaction between a buyer and a 

sella: in the following exemplary manner. An electronic invoice is first posted to the system 
by the seller or another system. Upon accepting the electronic invoice, the system creates 
one or more payment instructions. Each payment instruction corresponds to a payment 
transaction. Typically, one invoice represents one payment transaction, and hence, one 
30 payment instruction is created. However, it should be understood that multiple payment 
instructions may be created from a single invoice because a single invoice may represent 
multiple payment transactions. Alternatively, foe buyer can cause the Systran to create a 
payment instruction without a corresponding electronic invoice. 
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[121 Each time a payment instruction is created, the system applies some or all of 
the previously stored pre-negotiated payment terms and conditions between the buyer and the 
seller to the payment instruction. For example, if terms for a given buyer-seller contract state 
that payment is due 45 days from invoice date, mat information would be included in the 
5 payment instruction when the payment instruction is created. 

[13] After a payment instruction is created, the system seeks approval from the 
buyer. The approval can be provided by the buyer through an interface to the system 
Alternatively, the approval can be supplied by a third party system on behalf of the buyer. 
Upon approval of a payment instruction by the buyer, the system schedules the payment for 
10 the specified date in the payment instruction. On the scheduled day of payment, the system 
calculates one or more fees, such as a transaction fee, for that particular payment transaction 
according to a pre-defined variable pricing matrix, which is deterniined based on the set of 
pre-negotiated terms and conditions agreed to by the issuer, the acquirer, the seller and the 
buyer. 

15 [14] The transaction fee is an amount used by the issuer and the-acquirer to 

compensate each other for processing the payment transaction on behalf of the buyer and the 
seller. The respective portions of the transaction fee to be received by the issuer and the 
acquirer may vary. For example, the transaction fee may be shared by the issuer and the 
acquirer equally or based on some pre-deterroined percentage, or alternatively, the transaction 

20 fee may belong solely to the issuer. After the transaction fee is calculated, information 

relating to the transaction fee and the payment instruction is formatted into a proper message 
formats) and submitted for authorization, clearing and settlement The issuer and the 
acquirer then communicate with one another directly or indirectly to settle the funds. 
Additionally, the system provides transaction and activity reports to all relevant parties as 

25 well as access to status information for invoices and payments. 

[15] Accordingly, in an exemplary embodiment, a system for executing a payment 
transaction between a buyer and a seller, comprises: a first interface configured to allow 
invoices to be submitted for payment; a second interface configured to allow the buyer to 
receive and approve invoices and create and approve payment instructions; and a transaction 

30 processing module configured to handle buyer account(s) and seller accounts) respectively, 
the transaction processing module is further configured to store a plurality of conditions 
relating to die buyer, the seller, an issuer and an acquirer; and wherein the transaction 
processing module enables the issuer and the acquirer to process the invoices in accordance 
with the plurality of conditions. 

4 
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(161 Accordingly, in another exemplary embodiment, a method for processing a 
payment transaction between a buyer and a seller, comprises: mamtaining a buyer account 
and a seller account for the buyer and the seller respectively; maintaining a plurality of terms 
and conditions relating to the buyer, the seller, an issuer and an acquirer, approving the 
5 payment transaction for payment out of the buyer account; deterjnining a transaction fee for 
the payment transaction based on the plurality of terms and conditions; calculating anet 
amount using the transaction fee; obtaining payment authorization for the payment 
transaction from the issuer, and settling the payment transaction between toe issuer and the 
acquirer. 

10 [i7j Reference to toe remaining portions of the specification, including toe 

drawings and claims, will realize other features and advantages of the present invention. 
Further features and advantages of the present invention, as well as toe structure and 
operation of various embodiments of toe present invention, are described in detail below with 
respect to accompanying drawings, like reference numbers indicate identical or functionally 

15 similar elements. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[18] Fig. 1 is a simplified schematic diagram iuustrating toe process interaction of 
an exemplary embodiment of toe present invention; 
20 [19] Fig. 2 is a simplified schematic to'agram fflustratmg an exenmlary embodiment 

of toe transaction processing system in accordance with toe present invention; 

[20] Fig. 3 is a diagram ftlnstrating examples ^ 
Conditions; and 

[21] Fig. 4 is a flow diagram illustrating how toe net amount for each transaction is 
25 calculated in accordance with am exemplary embodiment of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 
[22] Referring to Fig. 1, there is shown toe process interaction of an exemplary 
embodiment of toe present invention. According to this exemplary embodiment, a 
30 transaction processing system 10 is designed to interact with a number of different parties 
involved in a transaction mcluding, abuyer 12, a seller 14, an issuer 16, an acqpirer 18 and a 
credit card association, such as Visa (via VisaNet). The buyer 12 can be a person or business 
entity which has contracted with toe seller 14 to purchase goods and/or services. 
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[231 Similarly, the seller 14 can be a person or business entity which has 
established a relationship with the buyer 12 to provide goods and/or services to the buyer 12. 
Such relationship is typically established via a written contract or agreement For example, 
the buyer 12 may enter into a contract with the seller 1 4 on a long-term basis to have the 
5 seller 12 be the exclusive provider of office supplies or other commodities for the buyer 12. 
The relationship between the buyer 12 and the seller 14 will be explained further below. 

[24] The issuer 1 6 can be a business entity which typically is a financial institution 
such as a bank. The issuer 1 6 issues one or more transaction accounts to the buyer 1 2 and is 
responsible for maintaining and handling the transaction account activities of the buyer 12 in 
10 cooperation with the transaction processing system 10. It should be noted that the issuer 16 
may issue and mfltntain transaction accounts for multiple buyers 12. 

[251 Similarly, the acquirer 18 can also be a business entity which typically is a 
financial institution such as a bank. The acquirer 1 8 is contracted with the seller 1 4 to accept 
seller sales drafts and instructions relating to the transaction accounts issued by issuer 16. 
15 Furthermore, the acquirer 18 also maintains one or more transaction accounts for the seller 14 
and is responsible for maintaining and handling the transaction account activities of the 
supplier 14 in cooperation with the transaction processing system 10. The acquirer 18 may 
also maintain similar accounts for multiple sellers 14. 

[26] Generally, the transaction processing system 10 stores and manages 
20 transaction accounts for buyers 12 and sellers 14 respectively. It should be understood that a 
single buyer 12 or seller 14 may have multiple transaction accounts from which payment can 
be debited and/or credited. In addition, the transaction processing system 10 stores and 
m aintains terms and conditions relating to those transaction accounts. These terms and 
conditions are usually provided to the transaction processing system 10 at the time of 
25 registration of the buyer 12 and/or the sella: 14. These terms and conditions include, for 
example, pre-negotiated payment teems and conditions between the buyer 12 and the seller 
1 4, which are to be used to govern transactions between the parties and can be obtained from 
various sources, such as a sales agreement between the buyer 12 and the seller 14. As will be 
further explained below, these terms and conditions are selectively used to process the 
30 transactions between the buyer 12 and the seller 14. 

[27] The transaction processing system 10 also provides the capability to store 
information relating to the issuers 16 and the acquirers 18. Such information can be used to 
determine the appropriate amount of transaction fee to be used by the issuer 16 and the 
acquirer 18 to compensate each other. 
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[28] Furthermore, the transaction processing Systran 10 also allows the issuer 16 
and the acquirer 18 to create and maintain buyer and sella: transaction accounts respectively. 
In order for the transaction processing system 10 to handle a transaction for the buyer 12 and 
the seller 14, both the buyer 12 and the seller 14 need to be registered or otherwise have their 

5 respective transaction accounts established with the transaction processing system 10. 
Additional details of the transaction processing system 10 will be further explained below. 

[29J The transaction processing system 10 operates in the following exemplary 
manner. The processing of a single invoice is illustrated below. However, it should be 
understood that multiple invoices can be processed by the transaction processing system 10 at 

10 the same time. As a preliminary step (not shown in Fig. 1), when the buyer 12 decides to 
purchase goods and/or services from the seller 14, the buyer 12 typically issues a purchase 
order, or via some other means communicates the purchase order, to the seller 14. Upon 
receiving the purchase order, the seller 14 then ships the ordered goods or provides a service 
to the buyer 12. 

15 [301 Referring now to Fig. 1, after receiving the purchase order, the seller 14 issues 

an electronic invoice either directly or indirectly through a complementary system (e.g., an e- 
procurement system) to the transaction processing system 10. In an exemplary embodiment, 
the transaction processing system 10 includes an interface which allows invoices to be posted 
directly by the seller 14 to the transaction processing system 10. 

20 [31J Upon accepting the invoice, the transaction processing system 10, in turn, 

creates one or more payment instructions. Each payment instruction corresponds to a 
payment transaction. Typically, one invoice represents one payment transaction, and hence, 
one payment instruction is usually created for each invoice. However, it should be 
understood that multiple payment instructions may be created from a single invoice because a 

25 single invoice may represent multiple payment transactions. The payment instruction 
includes payment terms and conditions between the buyer 12 and the seller 14 which are 
previously stored on the transaction processing system 10 and relevant to that particular 
payment transaction. Alternatively, the buyer 12 can cause a payment instruction to be 
generated by the transaction processing system 10 without any accompanying invoice. 

30 [32] After the payment instruction is created, the transaction processing system 10 

seeks approval for that payment instruction from the buyer 12. The approval can be provided 
by the buyer 12 through an interface to the transaction processing system 10. Alternatively, 
the approval can be supplied by a third party system on behalf of the buyer 12. Upon 
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approval 0 f the payment instruction by the buyer 12, the transaction processing system 10 
schedules the payment for the specified date in the payment instruction. 

[33] On the scheduled day of payment, the transaction processing system 10 
initiates processing of a payment from a transaction account belonging to the buyer 12 
5 pursuant to the payment instruction. 

[34] Upon initiation of processing of the approved payment instruction, the 
transaction processing system 10 first determines one or more fees, such as a transaction fee, 
for mat particular payment transaction. The transaction fee is an amount used by the issuer 
16 and the acquirer 18 to compensate each other for processing the payment transaction. The 
10 amount of the transaction fee is determined based on terms and conditions previously agreed 
to amongst the buyer 12, the seller 14, the issuer 16 and the acquirer 18. Furthermore, toe 
respective portions of the transaction fee to be received by the issuer 16 and the acquirer 18 
may vary depending on the arrangement agreed to between the issuer 16 and the acquirer 18. 
Determination of the transaction fee and these terms and conditions will be former explained 
15 below. 

[351 Using the transaction fee and other specified fees, if any, the transaction 
processing system 10 then calculates the net amount to be received by the seller 14 for the 
payment transaction being processed. Calculation of the net amount will be further described 
below. 

20 [36] The transaction processing system 10 also prepares an authorization request 

which is forwarded to the issuer 14 via a data transport and processing network 20, such as 
VisaNet 

[371 Once the authorization request is approved by the issuer 14, an authorizatiou 
response is sent by the issuer 14 to the transaction processing system 10. Upon receipt of the 

25 authorization response, the transaction processing system 10 forwards a settlement file to toe 
acquirer 18 via the data transport and processmg network 20. The settlement file includes, 
among other information, toe invoice amount (gross amount), toe transaction fee and toe net 
amount (the gross amount minus toe transaction fee and other specified fees, if any). 

[381 After toe settlement file is received by toe acquirer 18, toe acquirer 18 issues a 

30 request for the transfer of funds. The settlement of funds is then sent from toe issuer 16 to toe 
acquirer 18. This settlement of funds between the issuer 16 and toe acquirer 18 typically 
occurs within the data transport and processing network 20. The settlement of funds also 
occurs between toe buyer 12 and toe issuer 16 and between toe seller 14 and the acquirer 18. 
More specifically, the buyer 12 forwards or credits toe payment amount (or consolidated 
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payments) to the issuer 16 to cover for payment and processing of the payment transaction by 
the issuer 16 and the acquirer 18 credits the net amount to the seller 14. The settlement of 
funds between the buyer 12 and the issuer 16 and between the seller 14 and the acquirer 18 
occurs outside of the transaction processing system 10. 
5 [39] As shown in Fig. 1, in an exemplary embodiment, the transaction processing 

system 10 interacts with the data transport and processing network 20 in order to carry out 
certain payment processing, authorization and/or settlement functions. The data transport and 
processing network 20 globally connects the processing systems for all participating issuers 
16 and acquirers 18. As previously mentioned, an example of the data transport and 
10 processing network 20 is VisaNet 

[40] Referring to Fig. 2, there is shown an exemplary embodiment of the 
transaction processing system 10. According to mis exemplary embodiment, the transaction 
processing system 10 includes five components, namely, an invoice preprocessor 22, a 
payment manager 24, an issuer pricing engine 26, an authorization and settlement interface 
15 28 and a payment results manager 30. Preferably, these five components are implemented in 
a modular manner, however, it should be understood that they can be implemented in an 
integral manner as well. 

[41] It should also be understood that these five components are provided for 
illustrative purposes only. The transaction processing system 10 may include any number of 
20 components which collectively provide the functionality described herein. 

[42] The invoice pre-processor 22 manages input of seller invoices and 
consolidates these invoices into a standard file format The invoice pre-processor 22 is 
capable of accepting seller invoices in an electronic format Alternatively, the invoice pre- 
processor 22 may receive invoice data which is manually inputted. 
25 [43] In addition, it should be understood that the term "invoice" as used herein 

includes a typical invoice and any payment request pursuant to which an amount is to be paid 
from the buyer 12 to the seller 14. An invoice does not necessarily need to originate from the 
seller 14 but maybe originated from a third party system which issues the invoice on behalf 
of tihe seller 14. The buyer 12 cannot create an invoice, but can cause a payment instruction 
30 to be created without having received an invoice. 

[44] In any event the invoice pre-processor 22 generates a standardized invoice file 
which is then forwarded to the payment manager 24. In an exemplary implementation, the 
invoice pre-processor 22 combines all seller invoices into one standard file to be delivered as 
input into the payment manager 24. 
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[45] The payment manager 24 receives the standardized invoice file from the 
invoice pre-processor 22 and processes the standardized seller invoices. For each' invoice, Ihe 
payment manager 24 creates a corresponding payment instruction. The payment instruction 
includes certain pre-negotiated payment terms and conditions, if any, between the buyer 12 
5 and the seller 14 which are relevant to. the corresponding payment transaction. Alternatively, 
the buyer 12 can cause a payment instruction to be generated without any accompanying 
invoice. For example, the pre-negotiated payment terms and conditions may include payment 
timing information such as 2/10/het 30, etc. Other mfonnation can also be included to 
indicate that payments over a certain amount must be paid fester, or certain types of goods 
10 can be paid over a longer period of time, etc. In other words, this enables the buyer 12 to 

reference important contract terms mat do not relate directly to calculating the transaction fee. 
If no specific set of terms or conditions exists for that particular invoice or payment 
transaction, then a defiuilt set of terms and conditions may be used. It should be noted that 
tiie payment manager 24 may contain defiuilt sets of terms and conditions for various 
15 different buyers 12, sellers 14, issuers 16 and acquirers 18. 

[46] After tire payment instruction is created, the payment manager 24 seeks 
approval for that payment instruction from fee buyer 12. The approval can be provided by 
fee buyer 12 via an interfece to fee payment manager 24, or alternatively, fee approval can be 
supplied by a fend party system on behalf of fee buyer 12. In any event, upon approval of 
20 fee payment instruction by fee buyer 12, fee payment manager 24 schedules fee payment for 
fee specified date in fee payment instruction. On fee scheduled day of payment, fee payment 
manager 24 invokes fee issuer pricing engine 26 to process fee payment transaction, as will 
be described further below. 

[471 The payment manager 24 keeps track of fee status of each invoice or payment 
25 transaction. Each invoice or payment transaction may assume one of a number of status. A 
"scheduled" invoice is an invoice which is scheduled for payment on a particular due date. A 
"pending" invoice is an invoice for which an authorization request has already been issued 
A "declined" invoice is an invoice which has been refused by fee issuer 16. An "authorized" 
invoice is an invoice which has been approved by fee issuer 16. Finally, a "settled" invoice is 
30 an invoice for which settlement fund has already taken place. The payment manager 24 

cooperates wife fee payment results processor 30 to update fee status of each pending invoice 



on. 



[48J The payment manager 24 further provides various functions and services to 
fee buyer 12, fee seller 14, the issuer 16 and fee acquirer 18. 
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[49J With respect to the buyer 12, the payment manager 24 allows the buyer 12 to 
perform a number of tasks, mcluding, for example, (1) administering users belonging to the 
buyer 12, such as controlling user access levels and roles with identity authentication; (2) 
viewing and printing a listing of open invoices; (3) viewing payment terms and conditions for 
5 sellers presenting the invoices; (4) approving or rejecting invoices; (5) selecting invoices to 
pay from list of open invoices; (6) viewing payment status of invoices; (6) creating a payment 
for a seller if there is no associated invoice; (8) entering or selecting payment variables, such 
as amount, disbursement account and date, mcluding scheduling in advance for deferred 
settlement; (9) defining and enforcing payment approval process and authorization levels; 
10 (10) placing payments on hold or canceling payments; (1 1) viewing historical invoice or 
payment transactions; and (12) downloading invoice or payment data. 

[50] With respect to the seller 14, the payment manager 24 allows the seller 14 to 
create invoices and view the status of relevant invoices and payments. 

[511 With respect to the acquirer 18, the payment manager 24 allows the acquirer 
15 18 to create accounts for sellers 14 and their respective users. 

[52] With respect to the issuer 16, the payment manager 24 permits the issuer 16 to 
perform the following exemplary functions, including, for example, (1) entering payment 
account information for each buyer 12; (2) providing customer service to the buyer 12; and 
(3) creating accounts for additional buyers 12 and their respective users. 
20 [53] As mentioned above, on the scheduled day of payment, the payment manager 

24 invokes the issuer pricing engine 26 to process the payment transactions. More 
specifically, the issuer pricing engine 26 is invoked to determine one or more fees, such as a 
transaction fee, associated with each payment transaction. These fees maybe pre-aegotiated 
amongst and/or between the various parties including the issuer 16, the acquirer 18, the buyer 
25 12 and foe seller 14. For example, foe transaction fee is based on several parameters defined 
among the issuer 16, the acquirer 18, foe buyer 12 and foe seller 14. These parameters are 
collectively known as foe "Transaction Fee Terms and Conditions." The transaction fee is 
used by foe acquirer 18 and foe issuer 16 to compensate each other for each payment 
transaction. The respective portions of the transaction fee to be received by foe issuer 16 and 
30 foe acquirer 18 may vary depending on foe arrangement agreed to between foe issuer 16 and 
the acquirer 18. For example, foe issuer 16 and foe acquirer 18 may agree with each other to 
split foe transaction fee based on a pre-negotiated percentage, such as 50-50; alternatively, 
foe issuer 16 may be entitled to receive foe entire transaction fee. 
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1541 The Transaction Fee Terms and Conditions are negotiated between several 
parties, including, for example, (1) the buyer 12 and the seller 14; (2) the issuer 16 and the 
buyer 12; (3) the acquirer 18 and the seller 14; and (4) the issuer 16 and the acquirer 18. The 
issuer 16 is preferably responsible for defining, entering and maintaining the Transaction Fee 
5 Terms and Conditions using me payment manager 24. The Transaction Fee Terms and 

Conditions are stored in the issuer pricing engine 26 or another database and are accessible to 
the relevant parties. 

[551 Fig. 3 is a diagram fflustrating examples of the Transaction Fee Terms and 
Conditions. As shown in Fig. 3, for example, Transaction Fee Term #3 applies to every 
10 payment transaction for Issuer #9012. For Issuer #1234, Transaction Fee Term #1 only 
applies if a payment transaction is made between Buyer #95 and Seller #22 using account 
#121212. For Issuer #5678, since no account is specified, Transaction Fee Term #2 applies 
to every payment transaction between Buyer #1 8 and Seller #22. Other examples of the 
Transaction Fee and Terms and Conditions include a set of five transaction size ranges that 
15 apply to ahierarchy of relationships. The set of transaction size ranges may be payments 

between $0 -$500, $501 -$1000, $1001 -$5000, etc. These ranges can be established by the 
parties involved. For example, an individual matrix can be established for (1) each buyer and 
seller relationship, (2) for all sellers to a certain buyer, (3) for all sellers with a relationship to 
a certain acquirer, etc. Other Transaction Fee and Terms and Conditions may include 
20 additional fees for new value added services such as guaranteed payment 

[561 The net amount for each payment transaction is then calculated by subtracting 
the transaction fee fiom a gross amount The gross amount represents the payment amount 
which is to be paid by the buyer 12 for the payment transaction being processed. Optionally, 
additional fees may be deducted fiom the net amount For example, the acquirer 18 may 
25 require the seller 14 to pay other fees in order for the acquirer 18 to handle certain payment 
t ransact ions on behalf of the seller 14. 

[571 Fig.4isaflowdiagramulustratmgh 
the net amount for each payment transaction. At 40, the issuer pricing engine 26 receives the 
payment instruction corresponding to the payment transaction to be processed fiom the 
30 payment manager 24. At 42, the issuer pricing engine 26 attempts to retrieve a specific set of 
terms and conditions associated with that particular payment transaction for use in calculating 
the transaction fee. At 44, if a specific set of terms and conditions does not exist a default set 
of terms and conditions may be retrieved at 46. In any event, the set of terms and conditions 
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include information, such as pricing parameters, which is used to calculate the transaction 
foe. 

[58] At 48, for example, the transaction size ranges and their associated pricing 
fectors are obtained fiom within the retrieved set of terms and conditions. Each range may 

5 have different pricing fectors. For example, the pricing fector for the range of$0- $500 may 
be a basis rate which is based purely on percent calculation, such as 1 .5% of the gross 
amount; the pricing fector for the range of $501 to $632 may be 1% of the gross amount plus 
a flat fee of $5; the pricing fector for the range of $633 to $999 may be purely a flat fee, etc. 
At 50 , the transaction fee is calculated by applying the appropriate pricing factor against the 

10 gross amount As described above, the pricing fector may include a basis rate or percentage 
only, flat fee only or combination of the two with specific and defined values* It should be 
understood that other formulations or criteria may be used as the appropriate pricing fector. 

[59] At 52, the issuer pricing engine 26 determines whether the transaction fee is 
less than a minimum fee. The minimum fee is part of the negotiated fees in the variable 

15 pricing negotiation between issuers, acquirers, etc. At 54,* if it is determined that the 

transaction fee is less than the minimum fee, then the minimum fee is used as the transaction 
fee. 

[60J At 56, the issuer pricing engine 26 further determines whether die transaction 
fee exceeds a maximum fee. The maximum fee is also part of the negotiated fees in the 

20 variable pricing negotiation between issuers, acquirers, etc. If the transaction fee exceeds the 
maximum fee, thai, at 58, the rnayimum fee is used as die transaction fee. At 60, the net 
amount is calculated by subtracting the transaction fee from die gross amount For each 
payment transaction, the gross amount is the payment amount to be paid by the buyer 12, the 
transaction fee is the amount used by the acquirer 1 8 and the issuer 1 6 to compensate each 

25 other. The net amount is the amount to be received by the seller 14. Optionally, other fees 
may be deducted fiom flie net amount For example, the acquirer 18 may require the sella: 
14 to pay additional fees for processing of certain specified payment transactions. 

[61] Once the relevant amounts, such as the transaction fee and the net amount, are 
calculated, they are consolidated with other information into a calculated payment file for 

30 delivery to the authorization and settlement interfece 28. The calculated payment file is 
stored on an archive database or other storage medium for archival and reporting purposes. 

[621 The authorization and settlement interface 28 is responsible for transmitting 
and receiving payment transaction authorization and/or settlement information to and fiom 
the data transport and processing network 20. For each payment transaction, the data 
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transport and processing network 20 determines whether such transaction is authorized (by 
the issuer 16). Authorization and/or settlement results are then provided to the authorization 
and settlement interface 28. 

[63] The payment results manager 30 then receives the authorization and/or 

5 settlement results from the authorization and settlement interface 28 and further processes the 
results. The processed results are then passed back to the payment manager 24. The payment 
manager 24 men updates the status of the invoices or payment transactions and allows users 
to see whether payments for invoices have been settled or have been declined. 

[64] In an exemplary embodiment, the transaction processing system 10 is 

10 implemented on a server which is accessible via a computer network, such as die Internet 
Based on the disclosure provided herein, a person of ordinary skill in the art will know of 
ways and methods to implement the transaction processing system 10 on a server or other 
configuration. 

[65] Furthermore, in order to facilitate access by various users, the transaction 
15 processing system 10 also includes a number ofuser interfaces. The user interfaces allow 
different users to view and/or modify different information or data residing on the transaction 
processing system 10 depending on the access authority of such users. For example, an 
issuer 16 via a user interface may be able to view and modify certain Transaction Fee Terms 
and Conditions relating to its buyers 12. A buyer 12 via another user interface may be able to 
20 view invoices issued by its sellers 14. A person of ordinary skill in the art will know of other 
ways and methods to implement user interfaces via a computer network which allow 
information and data to be accessed. 

[66] It is understood that the examples and embodiments described herein are for 
illustrative purposes only and that various modifications or changes in light thereof will be 
25 suggested to persons skilled in the art and are to be included within the spirit and purview of 
mis application and scope of the appended claims. All publications, patents, and patent 
applications cited herein are hereby incorporated by reference for all purposes in then- 
entirety. 
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WR AT TS CLAIMED IS: 

1 1. A system for executing a payment transaction between a buyer and a 

2 seller, comprising: 

3 a module configured to allow the buyer to create and/or approve the payment 

4 transaction for payment; and 

5 a transaction processing module configured to handle a first account and a 

6 second account for the buyer and the seller respectively, the transaction processing module 

7 further configured to store a plurality of terms and conditions relating to the buyer, the seller, 

8 an issuer and an acquirer, 



9 wherein the transaction processing module cooperates with the issuer and the 

10 acquirer to process the payment transaction in accordance with the plurality of terns and 

11 conditions. 

1 2. The system according to claim 1 further comprising: 

2 a module configured to receive an invoice from the seller; 

3 wherein the invoice represents a request for payment for the payment 

4 transaction. 

1 3. The system according to claim 1 wherein the issuer manages the first 

2 account for the. buyer; and 

3 wherein the acquirer manages the second account for the seller. 

1 4. The system according to claim 1 wherein the transaction processing 

2 module determines one or more fees associated with the payment transaction based on the 

3 plurality of terns and conditions. 

1 5. Hie system according to claim 4 wherein die one or more fees include 

2 a transaction fee; and 

3 wherein the transaction fee is an amount used by die issuer and the acquirer to 

4 compensate each other for processing the payment transaction. 

1 6. The system according to claim 5 wherein the transaction module 

2 processing module calculates a net amount using the transaction fee; and 

3 wherein the net amount is an amount to be received by the seller from the 

4 payment transaction. 
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1 7. The system according to claim 6 wherein the net amount is calculated 

2 by subtracting the transaction fee from an invoice amount stated in the payment transaction. 

1 8. The system according to claim 1 wherein the transaction processing 

2 module cooperates with a data transport and processing network to fecilitate communication 

3 with toe issuer and toe acquirer. 

1 9. The system according to claim 1 wherein toe plurality of terms and 

2 conditions relating to the buyer, toe seller, toe issuer and toe acquirer are pre-negotiated terms 

3 and conditions agreed to amongst toe buyer, toe seller, the issuer and toe acquirer. 

1 10, Hie system according to claim 9 wherein one or more the prs- 

2 negotiated terms and conditions are obtained from a sales agreement between die buyer and 

3 tiie seller. 

1 11. The system according to claim 1 wherein at least one of the buyer, the 

2 seller, the issuer and the acquirer is authorized to modify one or more of the plurality of terms 

3 and conditions stored on the transaction processing module. 

1 12. A system for paying an invoice submitted by a seller to a buyer, 

2 comprising: 

3 an interfece configured to allow the buyer to approve payment for the invoice; 

4 and 

5 a transaction processing module configured to manage a buyer account for the 

6 buyer and a seller account for the seller, the transaction processing module further configured 

7 to store a plurality of terms and conditions pre-negotiated amongst the buyer, the sella:, an 

8 issuer and an acquirer, 

9 wherein the transaction processing module cooperates with the issuer and the 

10 acquirer to settle payment of the invoice in accordance with the plurality of terns and 

11 conditions. 

1 13. The system according to claim 12 wherein the interface is further 

2 configured to allow the buyer to select one of a plurality ofbuyer accounts to satisfy payment 

3 for the invoice. 
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1 14. The system according to claim 12 wherein the issuer manages the 

2 buyer account for the buyer, and 

3 wherein the acquirer manages the seller account for the seller. 

1 15. The system according to claim 12 wherein the transaction processing 

2 module determines one or more fees associated with the invoice based on the plurality of 

3 terms and conditions. 

1 16. The system according to claim 15 wherein the one or more fees include 

2 a transaction fee; and 

3 wherein the transaction fee is an amount to be used by the issuer and the 

4 acquirer to compensate each other for processing the invoice and settling payment therefor on 

5 behalf of the buyer and the sella- respectively. 

1 17. The system according to claim 16 where the transaction processing 

2 module calculates a net amount using the transaction fee; and 

3 wherein the net amount is an amount to be received by the sella: for the 

4 invoice. 

1 18. The system according to claim 17 wherein the net amount is calculated 

2 by subtracting the transaction fee from an invoice amount stated in the invoice. 

1 19. The system according to claim 12 wherein the transaction processing 

2 module cooperates with a data transport and processing network to fedlitate communication 

3 with the issuer and the acquirer. 

1 20. The system according to claim 16 wherein respective portions of the 

2 transaction fee to be received by the issuer and the acquirer vary depending on arrangement 

3 made between the issuer and the acquiror. 

1 21. A system for paying an invoice submitted by a seller to a buyer, 

2 comprising: 

3 a module configured to receive the invoice from the seller, the invoice 

4 representing one or more payment transactions; 
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5 a module configured to create a payment instruction for a corresponding 

6 payment transaction represented by the invoice and schedule payment for the corresponding 

7 payment transaction; 

8 a database configured to store a plurality of pre-negotiated terms and 

9 conditions amongst the buyer, the seller, an issuer and an acquirer, 

10 a transaction processing module configured to manage a buyer account for the 

1 1 buyer and a seller account for the seller, the transaction processing module further configured 

12 to process the corresponding payment transaction in accordance with the plurality ofpre- 

1 3 negotiated tarns and conditions when the scheduled payment is due. 

1 22. The system according to claim 21 further comprising: 

2 a module configured to receive approval of the payment instruction from the 

3 buyer. 

1 23. The system according to claim 21 wherein the transaction processing 

2 module determines one or more fees associated with the corresponding payment transaction 

3 based on the plurality of pre-negotiated terms and conditions. 

1 24. The system according to claim 23 wherein the one or more fees include 

2 a transaction fee; and 

3 wherein the transaction fee is an amount to be used by the issuer and the 

4 acquirer to compensate each other for processing the corresponding payment transaction and 

5 settling payment therefor on behalf of the buyer and the seller respectively* 

1 25. The system according to claim 24 wherein respective portions of the 

2 transaction fee to b e received by the issuer and the acquirer vary depending on arrangement 

3 made between the issuer and the acquirer. 

1 26. A system for processing payment transactions between sellers and 

2 buyers, comprising: 

3 an invoice processor configured to receive and process invoices received from 

4 the sellers and generate an output invoice file; 

5 a payment manager configured to maintain buyer accounts and seller accounts 

6 for the buyers and the sellers respectively, the payment manager further configured to receive 

7 the output invoice file and generate one or more payment instructions, each payment 

8 instruction corresponding to a payment transaction; 
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9 an issuer pricing engine configured to store a plurality of terms and conditions 

10 relating to the buyers, the sellers, issuers and acquirers, the issuer pricing engine further 

1 1 configured to calculate one or more fees and a net amount for each payment transaction based 

12 on relevant portions of the plurality of terms and conditions; 

13 an authorization and settlement interface configured to communicate with the 

14 issuers to obtain payment authorizations for the payment transactions respectively, and 

15 a payment results processor configured to report results relating to the 

16 payment authorizations for the payment transactions and provide the payment manager with 

17 the results so as to allow the payment manager to update the buyer accounts and the seller 

18 accounts. 

1 27. The system according to claim 26 wherein the issuers manage the 

2 buyer accounts for the buyers; and 

3 wherein the acquirers manage the seller accounts for the sellers. 

1 28. The system according to claim 26 wherein the one or more fees include 

2 a transaction fee; and 

3 wherein the transaction fee for each payment transaction is an amount used by 

4 a participating issuer and a participating acquirer to compensate each other for handling the 

5 payment transaction. 

1 29. The system according to claim 28 wherein the issuer pricing engine 

2 further calculates a net amount using the transaction fee for each payment transaction; and 

3 wherein the net amount is an amount to b e received by a seller involved in the 

4 payment transaction. 

1 30. The system according to claim 26 wherein the authorization and 

2 settlement interface cooperates with a data transport and processing network to facilitate 

3 communication with the issuers to obtain payment authorizations for the payment 

4 transactions. 

1 31. The system according to claim 26 wherein the plurality of terms and 

2 conditions relating to the buyers, the sellers, the issuers and the acquirers are pre-negotiated 

3 terms and conditions agreed to amongst the buyers, the sellers, the issuers and the acquirers. 
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1 32. The system according to claim 26 wherein the plurality of terms and 

2 conditions are modifiable. 

1 33. A method for processing a payment transaction between a buyer and a 

2 seller, comprising: 

3 maintaining a buyer account and a seller account for the buyer and the seller 

4 respectively; 

5 maintaining a plurality of terms and conditions relating to the buyer, the seller, 

6 an issuer and an acquirer, 

7 approving the payment transaction for payment out of the buyer account; 

8 determining one or more fees for the payment transaction based on the 

9 plurality oftenns and conditions; 

10 calculating a net amount using the transaction fee; 

1 1 obtaining payment authorization for the payment transaction from the issuer, 

12 and 

13 upon obtaining the payment authorization, settling the payment transaction 

14 between the issuer and the acquirer. 

1 34. The method according to claim 33 wherein the one or more fees 

2 include a transaction fee; and 

3 wherein the trans action fee is an amount to b e used by the issuer and the 

4 acquirer to compensate each other for settling the payment transaction on behalf ofthe buyer 

5 and the seller. 

1 35. The method according to claim 34 wherein respective portions ofthe 

2 transaction fee to be received by the issuer and the acquirer vary depending on arrangement 

3 made between the issuer and the acquirer. 

1 36. The method according to claim 33 wherein calculating the net amount 

2 further comprises: 

3 subtracting the transaction fee from an invoice amount stated in the payment 

4 transaction; 

5 wherein the net amount is an amount to be received by the seller forthe 

6 payment transaction. 
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1 37. The method according to claim 33 further comprising: 

2 upon obtaining the payment authorization, settling the payment transaction 

3 b etween the issuer and the buyer and b etween die acquirer and the seller. 

1 38. The method according to claim 33 further comprising: 

2 updating the plurality of terms and conditions. 

1 39. A method for processing invoices submitted by sellers to buyers, 

2 comprising: 

3 maintaining buyer accounts and seller accounts for the buyers and the sellers 

4 respectively; 

5 maintaining a plurality of terms and conditions relating to the buyers, the 

6 sellers, issuers and acquirers; 

7 with respect to each invoice, performing the following: 

8 identifying die involved buyer, sella:, issuer and acquirer, 

9 deteamining one or more fees based on portions of the plurality of 

1 0 teams and conditions relating to the involved buyer, sella:, issuer and acquirer, 

1 1 calculating a net amount using the transaction fee; 

12 obtaining payment authorization from the involved issuer, 

13 upon obtaining the payment authorization, settling payment of invoice 

14 between the involved issuer and acquirer. 

1 40. The method of claim 39 wherein for each invoice, the one or more fees 

2 include a transaction fee; and wherein die transaction fee is an amount to be used by the 

3 involved issuer and acquiror to compensate each other for processing the invoice on behalf of 

4 the involved buyer and seller. 

1 41. The method of claim 40 wherein respective portions of the transaction 

2 fee to be received by the issuer and the acquirer vary depending on arrangement made 

3 between the issuer and the acquirer. 

1 42. The method of claim 39 further comprising: 

2 upon settling payment of the invoices, updating the buyer accounts and the 

3 seller accounts. 
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